使用 GPT 或 Claude 時，我們通常期待模型替我們寫一段內容、解釋問題，或協助完成工作。但在應用程式裡，有些步驟需要的答案很簡單：這封客服信應該交給哪個部門？目前是否需要人工介入？這份資料是否符合指定條件？

今天要介紹的 Clef，就是為這類問題設計的 AI 決策模型。它由 Cloudflare 推出，可以讀取資料，根據開發者提供的問題與選項，回傳分類、機率或分數，讓程式決定下一步。

例如，客服系統收到「昨天被重複扣款，請協助退款」時，可以讓 Clef 判斷負責部門，再由程式將工單送進帳務佇列。它也可以成為 Agent 的工具，提供某個步驟需要的判斷。

本文會從第一次呼叫 Clef 開始，介紹它和 GPT、Claude 的差異、如何整合到 Agent，以及公開 benchmark 告訴我們什麼。

一、Clef 是什麼？它和 GPT、Claude 差在哪裡？

Clef 屬於 decision model，也就是決策模型。這類模型也常被稱為 System One model，主要用途是對範圍明確的問題做出判斷。

以客服信件為例，使用生成式模型時，我們可能會要求：

請理解客戶遇到的問題，查詢相關規定，並撰寫一封回覆。

這個任務包含閱讀、查詢、組織答案與文字生成。

使用 Clef 時，問題通常會縮小成：

這封信應該由帳務、技術、業務，還是人工分流處理？

開發者先定義允許的答案，Clef 再根據輸入資料評估各選項。程式可以直接讀取選擇結果，無須從一段解釋中尋找部門名稱。

Clef 和 Clef-Flash

目前官方提供兩個主要版本：

兩者都有開放權重，並提供 Workers AI 託管入口。Clef 系列也包含視覺能力，可把圖片納入判斷。

對第一次接觸的讀者，最直接的開始方式是呼叫託管 API。這樣可以先確認模型是否適合自己的問題，再考慮自行部署。

二、怎麼使用 Clef？先完成一次客服分類

使用 Clef 不需要先安裝 Agent 框架。一般 Python 程式就可以呼叫它。

這裡使用 Cloudflare Workers AI 的 REST API。它是 Cloudflare 提供的模型推論服務，程式透過網路送出資料，由服務執行模型並回傳結果。

第一步：取得帳號 ID 與 API token

依官方入門文件，先登入 Cloudflare 控制台，進入 Workers AI，選擇 Use REST API，再建立 Workers AI API Token，並複製 Account ID。

若自行建立 token，官方文件要求相應的 Workers AI Read 與 Edit 權限。
將這兩個值放進執行程式的環境變數：

export CLOUDFLARE_ACCOUNT_ID="你的帳號 ID"
export CLOUDFLARE_API_TOKEN="你的 API token"
python -m pip install requests

第二步：定義資料與問題

Clef 請求中最重要的兩個欄位是：

• state：本次要判斷的內容，例如一封客服信。
• questions：要問哪些問題，以及每個問題允許的答案。

以下範例只問一件事：應該交給哪個部門？

import os
import requests

account_id = os.environ["CLOUDFLARE_ACCOUNT_ID"]
token = os.environ["CLOUDFLARE_API_TOKEN"]
url = (
    f"https://api.cloudflare.com/client/v4/accounts/{account_id}"
    "/ai/run/@cf/cloudflare/clef"
)

payload = {
    "model": "clef",
    "state": "昨天同一筆訂單被扣款兩次，請協助確認並退款。",
    "questions": {
        "team": {
            "type": "choice",
            "instructions": "依信件主要問題選擇負責部門；無法確定時交人工分流。",
            "criteria": {
                "billing": "扣款、帳單、付款與退款問題",
                "technical": "登入失敗、功能錯誤與服務故障",
                "sales": "方案詢問、報價與升級",
                "review": "資訊不足或無法確定負責部門",
            },
        }
    },
}

response = requests.post(
    url,
    headers={"Authorization": f"Bearer {token}"},
    json=payload,
    timeout=30,
)
response.raise_for_status()
body = response.json()
if not body.get("success"):
    raise RuntimeError(body.get("errors"))
print(body["result"]["answers"]["team"])

這段程式是在本機執行 HTTP 請求，模型運算由 Cloudflare 執行；它不會啟動網頁介面，也不需要先部署 Cloudflare Worker。

team 是自行取的問題 ID。程式會在回應的 answers.team 找到相應答案，包含選擇結果與機率等資訊。

第三步：讓程式使用答案

如果 choice 是 billing，應用程式可以將工單標記為帳務類別。若是 review，則留在人工分流佇列。

但還應另外定義接受政策，例如：哪些結果可以自動分派、哪些必須人工確認。這個政策由程式控制，不是 Clef 看到 billing 就會自行修改客服系統。

完整流程會是：

客服系統收到信件 → 程式送出分類請求 → Clef 回傳判斷 → 程式檢查結果 → 寫入工單分類 → 畫面顯示負責部門。

若需要追蹤判斷，建議由自己的應用程式保存工單 ID、問題版本、模型識別、原始回應與最後採取的動作。一次 API 呼叫，不等於已建立可供產品查詢的決策紀錄。

除了分類，還能問什麼？

Clef 的三種問題形式可以放在同一份 questions 中：

要留意，Score 可以是依各等級機率計算出的加權值，不一定是整數等級。公開程式碼也顯示，該版本 Choice 的 confidence 取自被選中選項的機率。這是模型回傳數值的定義，不代表每個 0.9 的答案都已在你的資料上驗證為九成正確。

本機部署方式

Clef 提供兩種已有官方文件的本機使用方式：透過 Ollama 呼叫本機 API，或使用 Cloudflare 公開的 Python 程式直接載入模型。

如果希望像一般本機模型服務一樣使用，可以選擇 Ollama。Ollama 官方模型庫已提供 Clef，要求 Ollama 0.35.1 或更新版本。安裝並啟動 Ollama 後，先下載模型：

ollama pull clef

接著，將資料與問題送到本機的 http://localhost:11434/v1/systemone。例如，判斷一張客服工單應交給哪個部門：

curl http://localhost:11434/v1/systemone \
  -H "Content-Type: application/json" \
  -d '{
    "model": "clef",
    "state": "I was charged twice. Please refund the extra payment.",
    "questions": {
      "team": {
        "type": "choice",
        "instructions": "Which team should handle this ticket?",
        "criteria": {
          "billing": "Payments and refunds",
          "technical": "Bugs and outages"
        }
      }
    }
  }'

state 是待判斷的資料，questions 定義問題與允許的選項；回應中的 answers.team.choice 是選出的部門，probabilities 則包含各選項的機率。應用程式可以直接讀取這些欄位，安排後續流程。

若要將推論直接整合進 Python 程式，Cloudflare 的模型庫提供 joint_schema_model.py：先用 load_release_model() 載入基礎模型、專用決策模組與輸入處理器，再呼叫 systemone(model, processor, request)。其中 request 使用與上面相同的 model、state、questions 結構。這條路徑是在 Python 程序內執行；若要讓其他程式透過 HTTP 呼叫，還需要自行包裝成服務。

三、如何接到 Agent？

Clef 可以放進 Agent 的工具處理函式或固定工作流程。例如，將客服工單內容作為 state，把「帳務、技術、其他」定義成選項，再依回傳結果分派工單。

Codex、Claude Code 等環境可以透過自行封裝的 MCP 工具呼叫；使用 Agent SDK 或工具外掛時，則在工具的執行函式中呼叫 Clef API。這些都需要自行整合，核心工作是將業務資料轉成 Clef 的問題與選項，再把決策結果接到後續動作。

如果每張工單都必須分類，就應由工作流程固定呼叫 Clef；將它提供為 Agent 可選用的工具，並不能保證每筆資料都會經過分類。

四、Clef 和 Jev、Laya、Strands Decider 有什麼差異？

在比較這些決策模型之前，先認識它們共同提到的 System One，以及相容的 API 能讓我們沿用哪些東西。

System One 是什麼？它是協定嗎？

TypeSafe 創辦人 Diogo Almeida 在 2026 年 9 月 15 日的〈Introducing System One Models & Jev〉介紹 System One Models。名稱借用《快思慢想》的 System 1，強調快速、結構化的決策；Jev 是該公司推出的模型。

System One Models 是模型類型的稱呼；System One API 則是呼叫模型的介面規格。 後者使用 HTTP 傳送 JSON，定義如何提交待判斷的情境、問題與選項，以及如何取得答案。

TypeSafe 公開的 OpenAPI 規格包含：

哪些公司或專案採用？

以下都有官方文件或專案範例可確認：

實際請求與回應長什麼樣子？

以客服分類為例，取得 TypeSafe API key，並將它設定為 TYPESAFE_API_KEY 環境變數後，可以送出以下請求。範例依官方規格改寫：

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "我被重複扣款，請協助退回多收的費用。",
    "questions": {
      "team": {
        "type": "choice",
        "instructions": "這張工單應交給哪個部門？",
        "criteria": {
          "billing": "扣款、帳單與退款",
          "technical": "軟體錯誤與服務故障"
        }
      }
    }
  }'

state 放入需要判斷的資料；team 是應用程式自行命名的問題 ID。type: "choice" 指定這是一道選擇題，criteria 則定義允許的選項與各自的意思。

回應的範例如下：

{
  "answers": {
    "team": {
      "type": "choice",
      "choice": "billing",
      "confidence": 0.9,
      "probabilities": {
        "billing": 0.95,
        "technical": 0.05
      }
    }
  }
}

應用程式讀取 answers.team.choice，就能將工單交給帳務流程。完整回應還包含使用的 model 與用量資訊 usage。

同一份客服資料也能搭配其他問題：使用 noul 問「客戶是否要求退款」，或使用 score，依「一般、需盡快處理、立即處理」三個等級評估緊急程度。

共用介面後，四個模型還有哪些差異？

五、相關的 Benchmark

Decision Index：Cloudflare 公布的比較結果

Clef 模型卡列出 Cloudflare 執行 Decision Index 0.2.1 的結果。下面節錄四個項目；這些是該評測套件中的結果，應依其任務轉換與計分方式理解。

上述分數以百分比呈現，越高越好。

可以這樣理解：

• BANKING77 關注銀行客服意圖分類，較接近本文的分流情境。Macro-F1 會分別計算各類別表現，再做平均。
• BFCL 與工具／函式呼叫相關，但此處是決策評測中的版本；高分不等於完整 Agent 在真實環境中有同樣成功率。
• GPQA Diamond 涉及較困難的專業知識與推理。
• When2Call MCQ 關注是否需要使用工具的判斷。

這組結果支持的是：Clef 在這次客服意圖與工具相關測試中表現較好，而 Jev 在另外兩項領先。模型適合的工作，會隨問題類型改變。

S1MB：另一套社群評測提供不同角度

另一個可以參考的是 System One Mosaic Benchmark，簡稱 S1MB。它提供公開評測程式、資料與結果，英文套件包含 137 個 benchmark，分別測試 Choice、Noul 與 Score。

S1MB 的 Task Avg 先對各 benchmark 做基準調整，再分別彙整三種決策類型，最後等權平均。因此，Clef 的 55.97 不能解讀成「只答對 55.97%」。排行榜預設使用的 Borda Score 又是另一種依相對名次計分的方法，會受到參評模型集合影響。

這份結果裡，Clef 與 Jev 的 Choice 分數非常接近，但 Jev 的 Noul 與 Score 較高。它提供了比單一「總冠軍」更有用的選型資訊：如果產品主要做選項分類，應看 Choice；如果重度依賴評分，就要另外檢查 Score。

Laya 的兩列也必須依 checkpoint 名稱理解，不能直接代表多語言模型、後續版本或針對特定資料微調後的效果。

此外，S1MB 作者也開發自己的決策模型，並非沒有產品背景的中立測試機構；公開資料包含既有 NLP 資料與合成任務，作者明確提醒，成績不能證明訓練資料完全不重疊或未見任務的泛化能力。

Clef 與其他決策模型的回應時間

Cloudflare 公布的評測顯示，Clef-Flash 的中位回應時間約為 39 毫秒，Clef 約為 209 毫秒。同一份報告也列出其他決策模型的延遲：

P50 表示約一半請求在這個時間內完成；P95 則表示約 95% 的請求在這個時間內完成。

也有人比較決策模型與 GPT-5.4 mini，但本次找到的直接比較對象是 Jev，並非 Clef。 Agenteer 使用 BANKING77 的 154 則銀行客服訊息，讓兩個模型從相同的 77 種意圖中選擇答案。兩者都經過 Vercel AI Gateway；GPT-5.4 mini 使用結構化輸出，並將推理強度設為 none。

在這次客服分類測試中，Jev 的中位等待時間約為 GPT-5.4 mini 的四分之一；但 154 筆樣本尚未顯示明確的正確率差異。

References

• Cloudflare：Clef 官方介紹
• Cloudflare：REST API 入門
• Clef：模型卡與 Decision Index 結果
• S1MB：公開排行榜